---title: "Transcrição da Prova Teórica 1" matricula: "20243001649" nome: "Letícia Maurício de Souza" disciplina: "Gestão de Projetos de Software (GPS)" avaliacao: "Prova Teórica 1" data: "19/10/2026" nota_total: 21.7 legibilidade_global: "93%" classificacao: "Alta Legibilidade (90-100%)" observacoes_caligrafia: "Excelente caligrafia cursiva a caneta preta, traçado uniforme e organizado. Respondeu com alto nível conceitual e prático a todas as questões, com destaque para a análise de canais de comunicação, definição de pronto (DoD) e conciliação em Thomas-Kilmann." format: html: toc: true theme: cosmo pdf: documentclass: scrartcl papersize: a4 geometry: - margin=20mm --- # Avaliação Teórica 1 — Transcrição de Respostas ## Questão 1 — Ciclo de Vida e Fundamentos de Projetos * **Legibilidade da Questão:** 94% * **Gravidade de Leitura:** Normal ### 1.1 Projeto vs. Operação * **Resposta Manuscrita:** > O chatbot é um projeto, pois é uma grande aplicação, com diferentes fases (doc., código, testes), tem tarefas dependentes (o cód. depende da doc, integrar c/ LLM depende d system prompt) e exige um esforço longo e contínuo (o semestre). ### 1.2 Análise de Trade-off no Triângulo de Ferro * **Resposta Manuscrita:** > 1º) Entregar uma versão menor do software, reduzindo algumas funcionalidad.; pelo Triângulo, p/ manter tempo e custo é preciso reduzir o escopo. > 2º) Aumentar o prazo de entrega, pois mantém o escopo e os custos sem abrir mão da qualidade. ### 1.3 Ciclo de Vida do Projeto e Abordagem * **Resposta Manuscrita:** > Projeto longo com sprints de duração média, com abordagem híbrida, pois as sprints não são curtas com alinhamento super frequente, tem um tempo para ajuste da equipe, mas ainda tem entregas frequentes. --- ## Questão 2 — Escopo, EAP e Gestão de Backlog * **Legibilidade da Questão:** 92% * **Gravidade de Leitura:** Normal ### 2.1 Estrutura Analítica do Projeto (EAP) * **Diagrama / Elemento Visual:** ```text 1. Documentação 1.1. Project Charter 1.2. Diretrizes 1.3. Issues 2. Chatbot 2.1. Interface 2.2. Integração com LLM 2.3. System Prompt 3. Deploy 3.1. Config. Gitlab 3.2. Peer Review 3.3. Testes automatizados ``` * **Resposta Manuscrita:** > A EAP descreve o projeto e o organiza em detalhes, as tarefas possuem dependências e o proj. tem uma ordem natural a ser seguida para funcionar, mostrando o que é esperado e o que deve ser entregue, o que é importante. ### 2.2 Especificação de Issues de Backlog e Estimativas * **Resposta Manuscrita:** > Interface do Chatbot: criação do bot no Telegram de forma funcional, para funcionar como interface do professor agente, atuando na recepção e envio de mensagens. É preciso criar um usuário compatível com o proj. e armazenar a chave de forma segura no gitlab. P/ garantir sucesso, o chatbot deve receber a mensagem do usuário e devolver a mesma mensagem, em um método echo. Usando o botfather do próprio telegram, que é simples e de ampla documentação, mas considerando inexperiência, estimativa de 6h. Já para o project charter, estimativa de 3h, pois consiste em formalizar o que for decidido pela equipe, seguindo critérios já estabelecidos. ### 2.3 Milestones vs. Sprints no Modelo Ágil * **Resposta Manuscrita:** > Não, milestones não substituem sprints de forma equivalente. > Talvez Kanban sem sprints seja adequado em um proj. pequeno ou multirepo, que já possui separações, ou com outros tipos de tarefas, outros tipos de divisões, da mesma categoria das sprints. --- ## Questão 3 — Qualidade e Engenharia de Software com IA * **Legibilidade da Questão:** 94% * **Gravidade de Leitura:** Normal ### 3.1 Definição de Pronto (DoD) e Pipelines de CI/CD * **Resposta Manuscrita:** > DoD refere-se ao que é necessário para que uma tarefa/funcionalidade seja considerada concluída. Um dos itens obrigatórios p/ isso é passar nos testes automatizados, que devem ser config. de acordo com as métricas do projeto. Portanto, a funcionalidade não pode ser considerada pronta sem passar nos testes, que garantem que o que foi entregue corresponde ao que era esperado/especificado para aquele projeto, sem quebrar tudo. ### 3.2 Custo da Qualidade (CoQ) * **Resposta Manuscrita:** > a) Prevenção > b) Avaliação > c) Falha externa > d) Falha interna > A falha externa tende a ser o custo mais alto, pois é visível para o usuário, e pode gerar uma perda de credibilidade p/ a equipe e o produto, e podem ser violações de segurança graves, como vazamento de dados. ### 3.3 Heurística 1:10:100 e Testes em Software com IA * **Resposta Manuscrita:** > Em resumo, essa heurística nos diz que quanto mais cedo um erro for encontrado, mais barato é para corrigi-lo, isto é, é mais barato corrigir antes de se tornar uma falha e antes de chegar ao usuário. Em projetos com IA é mais complexo, pois não é possível prever 100% o comportamento de uma IA, não sabemos tudo sobre ela e o comportamento muda a todo momento, inclusive de acordo com o comportamento do usuário. O melhor é garantir testes de segurança em todas as fases, p/ que erros e bugs não sejam levados a diante no proj., mostrando que é melhor encontrar o erro e corrigi-lo o quanto antes. --- ## Questão 4 — Gestão de Riscos e Segurança * **Legibilidade da Questão:** 92% * **Gravidade de Leitura:** Normal ### 4.1 Classificação do Evento e Matriz de Riscos * **Diagrama / Elemento Visual:** * Posicionou no quadrante Médio (Probabilidade Baixa × Impacto Médio/Alto: "Commit acidental da chave da API"). * **Resposta Manuscrita:** > Era um risco, pois era um evento incerto, sem garantias de que ia ocorrer, enquanto um problema é algo que já ocorreu, risco que se concretizou. Coloco esse risco como médio, pois claramente tem um grande impacto no projeto, mas é um risco fácil de imaginar, e se devidamente mapeado o cuidado aumenta e a prob. diminui. Por ex. no nosso trab. no gitlab, uma vez que a chave foi config como var. oculta e colocada no .env e .gitignore, a prob. é praticamente nula e pode seguir assim até o fim do projeto. ### 4.2 Resposta a Incidentes e Defesa em Profundidade * **Resposta Manuscrita:** > Devemos revogar / trocar a chave da API; documentar como e porque isso ocorreu e mapear como risco no gitlab. O melhor é colocar a chave como variável oculta e protegida no gitlab, que permite rodar a aplicação lá mesmo. Além disso, .env no .gitignore p/ testes locais (token no .env, claro). ### 4.3 Modelagem de Ameaças em IA e Documentação Decisória * **Resposta Manuscrita:** > Seguindo a ordem do enunciado p/ prompt injection: a causa é o usuário do chatbot tentando burlar as diretrizes definidas pela equipe p/ obter respostas diretas e/ou outras coisas; a prob. é alta, pois até pessoas sem conhecimento podem fazer com ajuda de outras IAs; o impacto é alto, pois ele deixa de cumprir sua função de ajudar e o que foi definido pela equipe; isso deve ser considerado e verificado antes do prompt ser enviado para a LLM. P/ garantir que a saída não saia sem formatação, por ex., podemos mantê-la mais simplificada e/ou fazer verificações no código ou em outra LLM. > Recomendo colocar no project charter, que é a segurança da equipe e alvará do projeto. --- ## Questão 5 — Comunicação, Partes Interessadas e Conflitos * **Legibilidade da Questão:** 93% * **Gravidade de Leitura:** Normal ### 5.1 Canais de Comunicação e Rastreabilidade Decisória * **Resposta Manuscrita:** > A comun. síncrona permite uma com. mais clara e direta, melhor p/ problemas urgentes e importantes, mas quebra o ritmo de prog. e pode afetar a produtividade por causa disso, enquanto a assíncrona permite que a equipe responda no melhor momento de acordo com suas tarefas, mas pode fazer com que a equipe fique temporariamente desalinhada e uma situa. pode demorar dias até ser resolvida. P/ registro, as reuniões devem ter atas detalhadas, explicando as decisões e os motivos + pontos problemáticos e um canal oficial de com. c/ histórico, mensagens claras, sem conversa paralela, bem objetivo, acessível p/ toda a equipe. ### 5.2 Engajamento de Partes Interessadas (Poder × Interesse) * **Diagrama / Elemento Visual:** * **Manter Satisfeito:** 5 (Coordenação) * **Gerenciar de Perto:** 1, 3 (Alunos, Equipe) * **Monitorar:** 4 (Provedor API) * **Manter Informado:** 2 (Professor) * **Resposta Manuscrita:** > O professor não quer apenas o funcionamento da aplicação, mas os passos da gestão de projetos também, acompanhando e avaliando (poder e int.) o projeto, enquanto o aluno quer usar e quer o bom funcionamento, mas não acompanha e nem influencia diretamente as decisões do projeto. Com o professor nossa estratégia de com. envolve comunicação frequente através do gitlab, whatsapp e na sala de aula, para esclarecimento de dúvidas e alinhamento com o que ele espera. ### 5.3 Resolução de Conflitos e Modelo de Thomas-Kilmann * **Resposta Manuscrita:** > Resposta curta com pergunta socrática, pois os alunos não estão interessados em respostas longas que dizem o mesmo que respostas curtas, e mantém a LLM objetiva, reduzindo o risco de alucinar apenas para escrever mais palavras, mas pode dar uma resposta mais detalhada caso o usuário continue sem entender após algumas tentativas de explicações por parte do chatbot. Dessa forma, temos uma espécie de ganha-perde parcial / GANHA-GANHA, pois é impossível fazer as duas coisas ao mesmo tempo, mas não podemos aceitar TODAS as respostas longas e detalhadas, pois o risco é alto. Mantemos nossa decisão sem desconsiderar totalmente o cliente pedagógico. O meio termo total (resp. média) também não é o melhor, pois nenhum ficaria satisfeito total e o risco continua.